@gfyrag If you don't like type assertions let's discuss what some other options are?

My general idea was to keep logic related to Temporal as close to the activity definitions as possible. I wanted to avoid having any logic related to temporal implemented in the client packages themselves since they should just be concerned with communicating with the various APIs.

What I set out to achieve in this PR was:

1. API clients can return error interface without knowledge of temporal
2. a small subset of those errors, upon being unwrapped can be converted into temporal "NoRetry" errors

I suppose instead of a having an abstracted models.PluginError type I could create a generic function like

func toTemporalError(err error) *temporal.ApplicationError {
  if errors.Is(err, SomeErr) {
  } else if...
}

Is that really nicer than a quick type assertion though?

return nil, fmt.Errorf("failed to make payout, status code %d: %w", statusCode, err)
The original error is lost. It prevent a client from being capable to unwrap the errors.

How so? the %w embeds the error in a way that allows it to be unwrapped by errors.Is() later. Actually I am relying on that mechanic to be able to detect http 4xx statuses.

@gfyrag I removed the type assertion in favour of a simple function that uses errors.Is() to determine non-retryable errors as we discussed. I also added some regression tests which should fail if the plugin functions are refactored in a way which alters the errors they return.

I'am adding a comment here: everytime you do a c.httpClient.Do(req, &res, nil) which returns specific errors depending on the status code, you should do an errors.Wrap to keep the specific error instead of creating a new one

I'am adding a comment here: everytime you do a c.httpClient.Do(req, &res, nil) which returns specific errors depending on the status code, you should do an errors.Wrap to keep the specific error instead of creating a new one

My bad, now the idiomatic way to do it is with the %w !